Как бизнес смотрит на разработчиков?
Знакома ли тебе ситуация, когда заказчик смотрит на разработчика как на поставщика фич, а не как на члена команды, участвующего в развитии продукта? Бывает ли, что необходимость некоторых фич, которые хочет внедрить заказчик, неясна? Более того, нет понимания итоговых цифр и метрик проекта.
Нет точного ориентира, каким уровнем качества нужно обеспечить конкретную фичу. Нужен ли интерфейс или достаточно указывать настройки в файлах, нужно ли вынести функционал в микросервис или достаточно встроить его в текущую архитектуру и так далее…
При таком отношении разработчиков часто оценивают по количеству фич. Фактический уровень качества определяется в этом случае субъективно (по ситуации) или в зависимости от бюджета.
Но когда компания скатывается в ускорение фич, о качестве думать некогда. Никто не видит побед, многие достижения обесцениваются. Досадно, если, кроме технической команды, никто не может оценить красоту кода и вместо «как офигенно» маркетолог говорит: «Почему так долго, вот ещё пара задач, акция завтра».
Из-за сложившихся стереотипов может казаться, что это особенность аутсорса. Но всегда ли команда, которая развивает свой собственный продукт, избавлена от таких проблем? Правда ли, что в продуктовых компаниях нет заказчика, поэтому работать там можно в расслабленном темпе, спокойнее? Обсудим в этой статье, что же такое продуктовая разработка, в чём её особенности и почему она может отсутствовать в продуктовой компании, но быть у IT-интегратора.
Мифы о продуктовой и аутсорс-разработке
Под аутсорс-разработкой понимают работу по созданию софта на заказ — для внешних заказчиков.
Под продуктовой разработкой подразумевают создание и развитие собственного IT-продукта. Заказчик здесь внутренний, например это маркетинговый отдел или отдел продуктовой аналитики. Внутренний заказчик может мало чем отличаться от внешнего: он тоже требует определённого результата к определённому сроку. И ему важно, чтобы этот результат нужным образом приближал достижение его бизнес-целей.
Часто встречается мнение, что для аутсорса характерен проектный подход. Есть сроки и техническое задание: в сроки нужно вписаться, ТЗ — выполнить. От продуктовой же разработки ожидают продуктового подхода. Казалось бы, очевидно. Но давай разберёмся на практике, так ли это?
Продуктовый подход — это фокус на бизнес-целях: результат разработки должен решать конкретные задачи и быть рентабельным. «Продуктовый подход» не равно «продуктовая компания» — его вполне может применять и IT-интегратор!
Из-за сложившихся стереотипов о проектном и продуктовом подходах в среде разработчиков курсируют пять предрассудков об аутсорс-компаниях:
1 требования заказчиков постоянно меняются («им не угодишь»), критерии качества размыты;
2 труд разработчиков ценен только количеством реализованного функционала;
3 аутсорс — это работа в жёстких рамках, сроки всегда ограничены («надо было вчера»), работает конвейер (есть «план выработки» и норматив на выполнение операций);
4 работать на аутсорсе скучно и трудно, а вот создание собственных продуктов компании — это креатив, фонтан интересных и уникальных задач, решать которые легко и приятно;
5 качество кода, культура кода в продуктовой компании всегда выше.
Расскажем на примере компании kt.team, почему эти утверждения далеко не всегда справедливы. Мы придерживаемся продуктового подхода к разработке, хотя у нас есть не только собственные продукты, но и проекты на аутсорс. Познакомиться с некоторыми из них можно на странице «Проекты, над которыми мы работаем прямо сейчас». Не всех мы можем называть открыто, со многими действует NDA (соглашение о неразглашении).
Итак, разберёмся, насколько справедливы стереотипы про продуктовые и аутсорс-компании в IT.
Критерии качества
Миф об аутсорсинге
При работе на аутсорс качество оценивается субъективно, критерии качества размыты и зависят от прихоти заказчика, а требования могут меняться по пять раз в день («заказчику не угодишь»).
Миф о продуктовых компаниях
Команды разработчиков самостоятельно формируют объективные требования к качеству.
Реальность
Оценка качества зависит не от типа компании, а от принципов работы, принятых в ней, и от наличия объективных метрик.
Критерии качества размываются, когда заказчики относятся к разработчикам как к кодерам, безвольным исполнителям заказа. В таких случаях и возникают идеи оценивать труд, например, по количеству строк кода. Ведь другой ценности заказчик не видит.
Другое дело, когда компания позиционирует себя как партнёр по поставке IT-решений, и заказчики воспринимают её соответственно. Фичи и изменения обсуждаются совместно с учётом стратегических целей. В этом случае измерить качество гораздо проще: оно зависит от достижения целей.
Мы привыкли работать с заказчиками именно так.
Поэтому кодеров у нас в компании нет — только software-инженеры. Решения они принимают, ориентируясь на долгосрочные цели проекта, декомпозированную карту среднесрочных целей и метрики, которые сбалансированы по качеству и количеству.
Эти данные позволяют самостоятельно определять критерии достаточности качества: где достаточно захардкодить в константу, а где — сделать интерфейс управления, где предусмотреть гибкость и расширяемость, а где достаточно быстрого решения.
Пример
Мы создавали новый сервис для международной компании — производителя продуктов питания. Заказчик поставил цель: с помощью IT-инструментов достичь нужного уровня рентабельности.
Вместе с заказчиком мы посчитали, какие параметры юнит-экономики нам для этого нужны:
- увеличить средний чек — на 50 %;
- увеличить конверсию — незначительно;
- увеличить APC (average payment count, рус. среднее число платежей за год) — до 12, т. е. перевести в режим покупки продукта по ежемесячной подписке.
Провели анализ целевой аудитории, выделили два крупных сегмента: оптовые покупатели и мамочки.
Воронку продаж пересмотрели с точки зрения этих новых сегментов и построили план по развитию продукта на год. После достижения текущих целей будем масштабировать результат.
Признание заслуг
Миф об аутсорсинге
Есть стереотип, что в аутсорсинговых IT-компаниях менеджерам лишь бы побыстрее проект закрыть да акт подписать, а разбираться, кто молодец и где чья победа, некогда.
Миф о продуктовых компаниях
В продуктовых компаниях разработчики получают больше признания, потому что здесь они больше влияют на продукт и больше вовлекаются в процесс.
Реальность
Чтобы вклад каждого сотрудника оценивался справедливо, нужно заранее определить, кто за что отвечает, и установить объективные метрики — мы уже обсудили это в прошлом пункте.
Иногда разработчики отстраняются от целей бизнеса и говорят, что бизнес-метрики — это не их дело, «нужно просто качественно реализовывать свою задачу». В таком случае ничего странного, что заказчик низко ценит их труд. Он не видит их вклада в достижение целей. И даже если продукт полностью цифровой, победа будет чьей угодно, но только не IT-специалистов.
Маркетологи скажут, что это всё они, ведь за лиды и задачи по SEO были ответственны они.
Логисты скажут, что без остатков в каталоге и нормальной отгрузки продаж бы не было.
Начальник скажет, что это его прозорливое око за всем углядело.
Болтливый бездельник всем всё пообещает, и, даже если его обещания выполнит кто-то другой, это будет его победа.
Но если вдруг случится беда (а беду при определённом уровне управленческого зуда можно найти всегда), виноватым окажется разработчик. Ведь любую неудачу, тщательно покопавшись в аналитике, при большом желании можно привязать к любой цифре (а в нашей практике до работы с цифрами даже не доходит).
Вот только всё это с одинаковой вероятностью случается и в продуктовых, и в аутсорс-компаниях.
При продуктовом подходе победа — это не выполнение как можно большего количества фич, победа — это успешная гипотеза, которая позволила достичь бизнес-целей. И даже плохая гипотеза — не поражение, ведь она помогла лучше понять продукт и ускориться. Тут просто нет проигрышных ситуаций.
Таким образом, признание не зависит от того, работаешь ты в продуктовой компании или в аутсорсинговой. Главное — как изначально распределена ответственность за будущий результат между сторонами заказчика и исполнителя. Чтобы объективно оценивать вклад всех сторон, мы используем методику Impact Mapping. Статья об этом методе уже есть в блоге — «Impact Mapping, юнит-экономика и PDCA: грамотное управление разработкой e-Commerce».
Ещё три мифа об отличиях продуктовой разработки от аутсорсинга мы рассмотрим в следующей части статьи. Опубликуем её в субботу, 14 марта 2020 г. Следи за новостями ;)
